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Introduction 



• Autonomous Control (AC) refers to control actions 
of a system thattake place without intervention 
from humans. 

• AC denotes control actions that respond to events 
that a re unexpected, and enable the system to 
continue on a path to achieve an original objective 
or alternate objectives 

• Autonomous Control incorporates concepts such as 
adaptation, mitigation, and re- planning in space 
and time. 
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Fferadigm for Autonomy 



• Autonomy is a capability that is not absolute. There 
are degrees of autonomy, tanging from low levels 
to high levels, but there is no maximum level (how 
many autonomy strategies are implemented?). 

• It is an evolutionary capability that can handle 
increasing degrees of complexity for reasoning and 
decision making. 

• It must know the condition of the system elements 
and theirability to cany out the task. Integrated 
System Health Management (ISHM) then becomes 
an enabler for autonomy. 



Autonomy Strategies 



• Strategies for autonomy guide the decision making 
process. What to do when an element cannot be 
used? There must be a strategy to replace the 
fonction of that element in the cunent plan. 

• Autonomy is scripted to apply strategies* but it is 
more powerful when scripted ata high level of 
abstraction, that is* ata more generic KNOWLEDGE 
level. Where concepts are used instead of just data 
and infoimation. 
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Autonomy Approac h 



• During a mission, autonomy is ac hieved with four 
knowledge domains: System Domain Model (SDM), 
ISHM Domain Model (IDM), Autonomy Domain 
Model (ADM), and Mission Planning Domain Model 
(MPDM). 

• ISHM determines health and updates the SDM, 
Planerdeteiminesa course of action, and 
autonomy strategies help the Planner modify the 
course of action while considering health and 
objectives of a mission. 
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Autonomy Functional Diagram 



Sensorand Component 
Health 


Plan Sequence 








Software and Hardware Architectures for ISHM and 

Autonomy 


Hie software must enable the creation of domain 
models of the system which encapsulates 
infoimation and knowledge aboutall elements of 
the system and processes that can take place 
throughout the system (a knowledge base). 

Hie software and hardware architectures must 
make possible data, infoimation and knowledge 
(DlaK) management; such that data and 
infoimation is available to any element of the 
system when needed and for the right context 




Example Domain Model Representation 
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Hardware architecture showing Ibrdisbibuted ISHM-AC capability 

implementation. 
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AC-ISHM Integration Architecture 



Autonomous Control and ISHM 
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Software Architectures 



• Software architectures for ISHM and Autonomy mustenable 
the implementation of paradigms Id employ knowledge and 
information to achieve the desired functional capabilities. 

• In the case of ISHM, the goal is to determine the condition of 
every element in the system, by addressing the following: (1) 
anomaly detection, (2) diagnostics, (3) prognostics, (4) user 
interlaces for integrated awareness by the operator. 

• A software architecture for autonomy should enable the 
following capabilities: 

- Mission planning. 

- Resource assessment for mission execution. 

- Strategiesto add ness availability of resourcesto carry outa 
mission. 

- Strategies for mission re-planning to deal with unexpected 
circumstances. 
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Domain Models and Basic Knowledge Constructs 



Domain models are needed to encapsulate 
irribimation and knowledge associated with the 
system that is to operate autonomously. 

Four domain models provide the foundation for 
autonomy: (1) System Domain Model (SMD), (2) 
ISHM Domain Model (IDM), (3) Autonomy Domain 
Model (ADM) and (4) Mission Planning Domain 
Model (MPDM). 





14 







Domain Models for Autonomy 



• System Domain Model (SDM) 

- Ibis is the application domain model. 

- Encapsulates a II elements in the system, generally 
created from design diagrams(e.g. piping and 
Instrumentation dia grams or P&IDs). 

* ISHM Domain Model (IDM) 

- Encapsulates knowledge to achieve ISHM 
functionality (anomaly detection, diagnostics, 
prognostics, userinterfacesforintegrated awareness. 

- Usesthe SDM and updates ISHM para meters in the 
IDM to be consistent with the current condition of its 
elements. 
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Domain Models for Autonomy (Continued) 



* Autonomy Domain Model (ADM) 

- Strategiesto enable autonomy. 

• Determination of potential replacement elements (e.g. 
sensors). 

• Determination of alternate flow plaths. 

- Uses DlaK from the SDM and system condition 
information from the IDM. 

• Mission Planning Domain Model (MPDM) 

- Creation of mission plans to achieve an objective. 

- Realtime modification of mission plansguided by 
information from the ADM . 

- Uses DlaK from the SDM. 
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Reusability 



• DlaKto implement autonomy has a substantial 
portion of te-usable code. 

• Strategies for health managementand autonomy 
can be applied to many classes of systems. 

• the reason is that these strategies a re founded in 
engineering principles that apply to classes of 
systems. 

• For example a leak detection strategy may be to 
observe isolated subsystems (subsystems isolated 
by valves that a re closed), and see if pressures a re 
not steady. 
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* Autonomous systems a re intelligent systems by 
definition. 

* They incorporate information and knowledge that is 
evolving in time. 

• Architectures and software environments for autonomy 
must enable systematic evolution of the capability. 

• for example, any time there is a new strategy to 
deteimine that a sensor is fo ulty, one should be able to 
implement that strategy and make it part of the existing 
knowledge base of the domain model in a systematic 
manner, without affecting existing code. And the new 
strategy should be integrated automatically. 
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Pilot Implementation: Autonomous Management of 
Ciyogenic Huidsata Roc ket Launch Pad lestbed 
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System Domain Model: lop Domain Map 
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Autonomous Control Operations Client to the 
Knowledge Domain Model 
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R1EA Program for Leak Detection 
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Autonomous Control Sequence Capability 


1. Sequence Creation, loading, and execution. 

a. Sequences can be seen as mission plans. 

b. The system enables quick and easy creation of sequences with menus. 

c. Sequences are represented in tabular and graphical formats. 

d. Sequences can be verified by simulating conditions that enable actions to be executed. 

e. Sequences can be saved and loaded as needed. 

f. Sequence conditions include: 

a. Sensor triggers. 

b. Redline triggers. 

c. Fluid saturation state. 

d. Redline sensor failure 

e. May include other conditions from health or other algorithm outcomes. 

g. Sequence actions include: 

a. Valve and pump operations. 

b. Camera pointing. 

c. Execution of special sequences such as shut-down or reverting to a prior step. 

d. May include execution of any sequence that responds to system conditions and planning. 
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Autonomous Control Sequence Creation and 

Simulation 
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Autonomous Control Sequence Simulation 
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Autonomous Control Sequence Execution 
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Autonomous Control: Monitors and Console 



ALL Monitors - Click STATUS to manually ACTIVATE/ DEACTIVATE — Click PLAN to ; 
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Autonomous Control: Monitor C reation 
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On Going Development 



• Will use validated tec hnology to implement 
autonomous propellant loading on a pilot launch 
system atKSC. 

• Target mobile launc h c lass systems. 

• Will demonstrate a utonomous operations of multi- 
tank systems, managing simultaneously operational 
sequences for ciyogenic oxidizer and fuel systems. 
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Backup 
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CTL System Description 



• HM- PIPE: 2168 (Pipe elements) 

• HM- PRESSURE- SENSOR: 62 (Pressure Sensors) 

• HM-1EMPERA1URE- SENSOR: 22 (Temperature Sensors) 

• HM- VALVE: 286 (Valves) 

• HM-ELECTRICAL-CONNECTION: 100 (Bee trie a I 
Connections) 
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